home *** CD-ROM | disk | FTP | other *** search
/ The CICA Windows Explosion! / The CICA Windows Explosion! - Disc 2.iso / nt / gr564s.zip / README < prev    next >
Text File  |  1993-09-07  |  22KB  |  505 lines

  1. This directory contains complete sources for RCS version 5.6.0.1.
  2.  
  3. RCS, the Revision Control System, manages multiple revisions of files.
  4. RCS can store, retrieve, log, identify, and merge revisions.
  5. It is useful for files that are revised frequently,
  6. e.g. programs, documentation, graphics, and papers.
  7.  
  8. /* Copyright (C) 1982, 1988, 1989 Walter Tichy
  9.    Copyright 1990, 1991, 1992 by Paul Eggert
  10.    Distributed under license by the Free Software Foundation, Inc.
  11.  
  12. This file is part of RCS.
  13.  
  14. RCS is free software; you can redistribute it and/or modify
  15. it under the terms of the GNU General Public License as published by
  16. the Free Software Foundation; either version 2, or (at your option)
  17. any later version.
  18.  
  19. RCS is distributed in the hope that it will be useful,
  20. but WITHOUT ANY WARRANTY; without even the implied warranty of
  21. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  22. GNU General Public License for more details.
  23.  
  24. You should have received a copy of the GNU General Public License
  25. along with RCS; see the file COPYING.  If not, write to
  26. the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
  27.  
  28. Report problems and direct all questions to:
  29.  
  30.     rcs-bugs@cs.purdue.edu
  31.  
  32. */
  33.  
  34. $Id$
  35.  
  36.  
  37. Installation notes:
  38.  
  39.   RCS requires a diff that supports the -n option.
  40.   Get GNU diff (version 1.15 or later) if your diff lacks -n.
  41.  
  42.   RCS works best with a diff that supports -a and -L,
  43.   and a diff3 that supports -E and -m.
  44.   GNU diff supports these options.
  45.  
  46.   Sources for RCS are in the src directory.
  47.   Read the directions in src/README to build RCS on your system.
  48.  
  49.   Manual entries reside in man.
  50.  
  51.   Troff source for the paper `RCS--A System for Version Control', which
  52.   appeared in _Software--Practice & Experience_, is in rcs.ms.
  53.  
  54.   If you don't have troff, you can get GNU groff to format the documentation.
  55.  
  56.  
  57. RCS compatibility notes:
  58.  
  59.   RCS version 5 reads RCS files written by any RCS version released since 1982.
  60.   It also writes RCS files that these older versions of RCS can read,
  61.   unless you use one of the following new features:
  62.  
  63.     checkin times after 1999/12/31 23:59:59 GMT
  64.     checking in non-text files
  65.     identifiers containing `.' or non-Ascii bytes, or starting with a digit
  66.     rcs -bX, where X is nonempty
  67.     rcs -kX, where X is not `kv'
  68.     RCS files that exceed hardcoded limits in older RCS versions
  69.  
  70.   A working file written by RCS 5.5 or later contains four-digit years in its
  71.   keyword strings.  If you check out a working file with RCS 5.5 or later,
  72.   an older RCS version's `ci -k' may insist on two-digit years.
  73.   Fix this with `co -V4', or by editing the working file.
  74.  
  75. See Version for the version number of this release.
  76.  
  77. Features new to RCS version 5.6.* (beta) include:
  78.  
  79.   A new DIFF3_A configuration flag for GNU diff3 2.1 and later;
  80.   see src/README.
  81.  
  82.   ci's -rR option (with a nonempty R) now just specifies a revision number R.
  83.   Formerly, it also reestablished the default behavior of releasing a lock and
  84.   removing the working file.  Now, only the bare -r option does this.
  85.  
  86.   With an empty extension, any appearance of a directory named `RCS'
  87.   in a pathname identifies the pathname as being that of an RCS file.
  88.   For example, `a/RCS/b/c' is now an RCS file with an empty extension.
  89.   Formerly, `RCS' had to be the last directory in the pathname.
  90.  
  91.   The new -T option of ci, co, rcs, and rcsclean preserves the modification
  92.   time of the RCS file unless a revision is added or removed.
  93.  
  94.   rcs's new -M option causes it to not send mail when you break somebody
  95.   else's lock.  This is not meant for casual use; see rcs(1).
  96.  
  97.   If someone else already holds the lock, rcs -l now asks whether you want
  98.   to break it, instead of immediately reporting an error.
  99.  
  100.   ci now always unlocks a revision like 3.5 if you check in a revision
  101.   like 3.5.2.1 that is the first of a new branch of that revision.
  102.   Formerly it was inconsistent.
  103.  
  104.   ci's new -i option causes an error if the RCS file already exists.
  105.   Similarly, -j causes an error if the RCS file does not already exist.
  106.  
  107.   Identifiers may now start with a digit and (unless they are symbolic names)
  108.   may contain `.'.  This permits author names like `john.doe' and `4tran'.
  109.  
  110.   A bare -V option now prints the current version number.
  111.  
  112.   rcsdiff outputs more readable context diff headers if diff -L works.
  113.  
  114.   rcsdiff -rN -rN now suppresses needless checkout and comparison
  115.   of identical revisions.
  116.  
  117.  
  118. Features new to RCS version 5.6 include:
  119.  
  120.   Security holes have been plugged; setgid use is no longer supported.
  121.  
  122.   co can retrieve old revisions much more efficiently.
  123.   To generate the Nth youngest revision on the trunk,
  124.   the old method used up to N passes through copies of the working file;
  125.   the new method uses a piece table to generate the working file in one pass.
  126.  
  127.   When ci finds no changes in the working file,
  128.   it automatically reverts to the previous revision unless -f is given.
  129.  
  130.   RCS follows symbolic links to RCS files instead of breaking them,
  131.   and warns when it breaks hard links to RCS files.
  132.  
  133.   `$' stands for the revision number taken from working file keyword strings.
  134.   E.g. if F contains an Id keyword string,
  135.   `rcsdiff -r$ F' compares F to its checked-in revision, and
  136.   `rcs -nL:$ F' gives the symbolic name L to F's revision.
  137.  
  138.   co and ci's new -M option sets the modification time
  139.   of the working file to be that of the revision.
  140.   Without -M, ci now tries to avoid changing the working file's
  141.   modification time if its contents are unchanged.
  142.  
  143.   rcs's new -m option changes the log message of an old revision.
  144.  
  145.   RCS is portable to hosts that do not permit `,' in filenames.
  146.   (`,' is not part of the Posix portable filename character set.)
  147.   A new -x option specifies extensions other than `,v' for RCS files.
  148.   The Unix default is `-x,v/', so that the working file `w' corresponds
  149.   to the first file in the list `RCS/w,v', `w,v', `RCS/w' that works.
  150.   The non-Unix default is `-x', so that only `RCS/w' is tried.
  151.   Eventually, the Unix default should change to `-x/,v'
  152.   to encourage interoperability among all Posix hosts.
  153.  
  154.   A new RCSINIT environment variable specifies defaults for options like -x.
  155.  
  156.   The separator for revision ranges has been changed from `-' to `:', because
  157.   the range `A-B' is ambiguous if `A', `B' and `A-B' are all symbolic names.
  158.   E.g. the old `rlog -r1.5-1.7' is now `rlog -r1.5:1.7'; ditto for `rcs -o'.
  159.   For a while RCS will still support (but warn about) the old `-' separator.
  160.  
  161.   RCS manipulates its lock files using a method that is more reliable under NFS.
  162.  
  163.   Experimental support for MS-DOS and OS/2 is available as part of a separate
  164.   software distribution.
  165.  
  166.  
  167. Features new to RCS version 5 include:
  168.  
  169.   RCS can check in arbitrary files, not just text files, if diff -a works.
  170.   RCS can merge lines containing just a single `.' if diff3 -m works.
  171.   GNU diff supports the -a and -m options.
  172.  
  173.   RCS can now be used as a setuid program.
  174.   See ci(1) for how users can employ setuid copies of ci, co, and rcsclean.
  175.   Setuid privileges yield extra security if the effective user owns RCS files
  176.   and directories, and if only the effective user can write RCS directories.
  177.   RCS uses the real user for all accesses other than writing RCS directories.
  178.   As described in ci(1), there are three levels of setuid support.
  179.  
  180.     1.  Setuid works fully if the seteuid() system call lets any
  181.     process switch back and forth between real and effective users,
  182.     as specified in Posix 1003.1a Draft 5.
  183.  
  184.     2.  On hosts with saved setuids (a Posix 1003.1-1990 option) and without
  185.     a modern seteuid(), setuid works unless the real or effective user is root.
  186.  
  187.     3.  On hosts that lack both modern seteuid() and saved setuids,
  188.     setuid does not work, and RCS uses the effective user for all accesses;
  189.     formerly it was inconsistent.
  190.  
  191.   New options to co, rcsdiff, and rcsmerge give more flexibility to keyword
  192.   substitution.
  193.  
  194.     -kkv substitutes the default `$Keyword: value $' for keyword strings.
  195.     However, a locker's name is inserted only as a file is being locked,
  196.     i.e. by `ci -l' and `co -l'.  This is normally the default.
  197.  
  198.     -kkvl acts like -kkv, except that a locker's name is always inserted
  199.     if the given revision is currently locked.  This was the default in
  200.     version 4.  It is now the default only with when using rcsdiff to
  201.     compare a revision to a working file whose mode is that of a file
  202.     checked out for changes.
  203.  
  204.     -kk substitutes just `$Keyword$', which helps to ignore keyword values
  205.     when comparing revisions.
  206.  
  207.     -ko retrieves the old revision's keyword string, thus bypassing keyword
  208.     substitution.
  209.  
  210.     -kv retrieves just `value'.  This can ease the use of keyword values, but
  211.     it is dangerous because it causes RCS to lose track of where the keywords
  212.     are, so for safety the owner write permission of the working file is
  213.     turned off when -kv is used; to edit the file later, check it out again
  214.     without -kv.
  215.  
  216.   rcs -ko sets the default keyword substitution to be in the style of co -ko,
  217.   and similarly for the other -k options.  This can be useful with binary file
  218.   formats that cannot tolerate changing the lengths of keyword strings.
  219.   However it also renders a RCS file readable only by RCS version 5 or later.
  220.   Use rcs -kkv to restore the usual default substitution.
  221.  
  222.   RCS can now be used by development groups that span timezone boundaries.
  223.   All times are now displayed in GMT, and GMT is the default timezone.
  224.   To use local time with co -d, append ` LT' to the time.
  225.   When interchanging RCS files with sites running older versions of RCS,
  226.   time stamp discrepancies may prevent checkins; to work around this,
  227.   use `ci -d' with a time slightly in the future.
  228.  
  229.   Dates are now displayed using four-digit years, not two-digit years.
  230.   Years given in -d options must now have four digits.
  231.   This change is required for RCS to continue to work after 1999/12/31.
  232.   The form of dates in version 5 RCS files will not change until 2000/01/01,
  233.   so in the meantime RCS files can still be interchanged with sites
  234.   running older versions of RCS.  To make room for the longer dates,
  235.   rlog now outputs `lines: +A -D' instead of `lines added/del: A/D'.
  236.  
  237.   To help prevent diff programs that are broken or have run out of memory
  238.   from trashing an RCS file, ci now checks diff output more carefully.
  239.  
  240.   ci -k now handles the Log keyword, so that checking in a file
  241.   with -k does not normally alter the file's contents.
  242.  
  243.   RCS no longer outputs white space at the ends of lines
  244.   unless the original working file had it.
  245.   For consistency with other keywords,
  246.   a space, not a tab, is now output after `$Log:'.
  247.   Rlog now puts lockers and symbolic names on separate lines in the output
  248.   to avoid generating lines that are too long.
  249.   A similar fix has been made to lists in the RCS files themselves.
  250.  
  251.   RCS no longer outputs the string `Locker: ' when expanding Header or Id
  252.   keywords.  This saves space and reverts back to version 3 behavior.
  253.  
  254.   The default branch is not put into the RCS file unless it is nonempty.
  255.   Therefore, files generated by RCS version 5 can be read by RCS version 3
  256.   unless they use the default branch feature introduced in version 4.
  257.   This fixes a compatibility problem introduced by version 4.
  258.  
  259.   RCS can now emulate older versions of RCS; see `co -V'.
  260.   This may be useful to overcome compatibility problems
  261.   due to the above changes.
  262.  
  263.   Programs like Emacs can now interact with RCS commands via a pipe:
  264.   the new -I option causes ci, co, and rcs to run interactively,
  265.   even if standard input is not a terminal.
  266.   These commands now accept multiple inputs from stdin separated by `.' lines.
  267.  
  268.   ci now silently ignores the -t option if the RCS file already exists.
  269.   This simplifies some shell scripts and improves security in setuid sites.
  270.  
  271.   Descriptive text may be given directly in an argument of the form -t-string.
  272.  
  273.   The character set for symbolic names has been upgraded
  274.   from Ascii to ISO 8859.
  275.  
  276.   rcsdiff now passes through all options used by GNU diff;
  277.   this is a longer list than 4.3BSD diff.
  278.  
  279.   merge's new -L option gives tags for merge's overlap report lines.
  280.   This ability used to be present in a different, undocumented form;
  281.   the new form is chosen for compatibility with GNU diff3's -L option.
  282.  
  283.   rcsmerge and merge now have a -q option, just like their siblings do.
  284.  
  285.   RCS now attempts to ignore parts of an RCS file that look like they come
  286.   from a future version of RCS.
  287.  
  288.   When properly configured, RCS now strictly conforms with Posix 1003.1-1990.
  289.   RCS can still be compiled in non-Posix traditional Unix environments,
  290.   and can use common BSD and USG extensions to Posix.
  291.   RCS is a conforming Standard C program, and also compiles under traditional C.
  292.  
  293.   Arbitrary limits on internal table sizes have been removed.
  294.   The only limit now is the amount of memory available via malloc().
  295.  
  296.   File temporaries, lock files, signals, and system call return codes
  297.   are now handled more cleanly, portably, and quickly.
  298.   Some race conditions have been removed.
  299.  
  300.   A new compile-time option RCSPREFIX lets administrators avoid absolute path
  301.   names for subsidiary programs, trading speed for flexibility.
  302.  
  303.   The configuration procedure is now more automatic.
  304.  
  305.   Snooping has been removed.
  306.  
  307.  
  308. Version 4 was the first version distributed by FSF.
  309. Beside bug fixes, features new to RCS version 4 include:
  310.  
  311.   The notion of default branch has been added; see rcs -b.
  312.  
  313.  
  314. Version 3 was included in the 4.3BSD distribution.
  315.  
  316.  
  317. Further projects:
  318.  
  319.   Add a -z option to use a time zone other than GMT; this could be in RCSINIT.
  320.   -zLT would use local time; -z+0500 would be 5 hours ahead of GMT; etc.
  321.   RCS files themselves will not be affected and will always use GMT,
  322.   but working files and (especially) rlog output will be affected.
  323.   If -z is specified, numeric GMT offset is displayed after the time.
  324.   ci -k will parse GMT offsets.
  325.  
  326.   Bring back sccstorcs.
  327.  
  328.   Add format options for finer control over the output of ident and rlog.
  329.   E.g. there should be an easy way for rlog to output lines like
  330.   `src/main.c 2.4 wft', one for each locked revision.
  331.  
  332.   rlog -rM:N should work even if M and N have different numbers of fields,
  333.   so long as M is an ancestor of N or vice versa.
  334.  
  335.   rcs should evaluate options in order; this allows rcs -oS -nS.
  336.  
  337.   Be able to redo the most recent checkin with minor changes.
  338.  
  339.   co -u shouldn't complain about a writable working file if it won't change
  340.   its contents.
  341.  
  342.   Configure the Makefile automatically, as well as conf.h.
  343.  
  344.   Add a `-' option to take the list of pathnames from standard input.
  345.   Perhaps the pathnames should be null-terminated, not newline-terminated,
  346.   so that pathnames that contain newlines are handled properly.
  347.  
  348.   Add general options so that rcsdiff and rcsmerge can pass arbitrary options
  349.   to its subsidiary co and diff processes.  E.g.
  350.  
  351.     -.OPTION to pass OPTION to the subsidiary `co'
  352.     -/OPTION to pass OPTION to the subsidiary `diff' (for rcsdiff only)
  353.  
  354.   For example:
  355.  
  356.     rcsdiff -.-d"1991/02/09 18:09" -.-sRel -/+unified -/-C -/5 -/-d foo.c
  357.  
  358.   invokes `co -d"1991/02/09 18:09" -sRel ...' and `diff +unified -C 5 -d ...'.
  359.   To pass an option to just one subsidiary `co', put the -. option
  360.   after the corresponding -r option.  For example:
  361.  
  362.     rcsmerge -r1.4 -.-ko -r1.8 -.-kkv foo.c
  363.  
  364.   passes `-ko' to the first subsidiary `co', and `-kkv' to the second one.
  365.  
  366.  
  367.   Permit multiple option-pathname pairs, e.g. co -r1.4 a -r1.5 b.
  368.  
  369.   Add ways to specify the earliest revision, the most recent revision,
  370.   the earliest or latest revision on a particular branch, and
  371.   the parent or child of some other revision.
  372.  
  373.   If a user has multiple locks, perhaps ci should fall back on ci -k's
  374.   method to figure out which revision to use.
  375.  
  376.   Symbolic names need not refer to existing branches and revisions.
  377.   rcs(1)'s BUGS section says this is a bug.  Is it?  If so, it should be fixed.
  378.  
  379.   Add an option to rcs -o so that old log messages are not deleted if
  380.   the next undeleted revision exists, but are merely appended to the log
  381.   message of that revision.
  382.  
  383.   Use the prefix before `$Log' as the comment leader by default.
  384.  
  385.   ci -k should be able to get keyword values from the first `$Log' entry.
  386.  
  387.   Add a new keyword `$Symbols' that expands to this revision's symbolic names.
  388.  
  389.   Add an option to rcsclean to clean directories recursively.
  390.  
  391.   Write an rcsck program that repairs corrupted RCS files,
  392.   much as fsck repairs corrupted file systems.
  393.  
  394.   Clean up the source code with a consistent indenting style.
  395.  
  396.   Update the date parser to use the more modern getdate.y by Bellovin,
  397.   Salz, and Berets, or the even more modern getdate by Moraes.  None of
  398.   these getdate implementations are as robust as RCS's old warhorse in
  399.   avoiding problems like arithmetic overflow, so they'll have to be
  400.   fixed first.
  401.  
  402.   Break up the code into a library so that it's easier to write new programs
  403.   that manipulate RCS files, and so that useless code is removed from the
  404.   existing programs.  For example, the rcs command contains unnecessary
  405.   keyword substitution baggage, and the merge command can be greatly pruned.
  406.  
  407.   Make it easier to use your favorite text editor to edit log messages,
  408.   etc. instead of having to type them in irretrievably at the terminal.
  409.  
  410.   Let the user specify a search path for default branches,
  411.   e.g. to use L as the default branch if it works, and M otherwise.
  412.   Let the user require that at least one entry in the default branch path works.
  413.   Let the user say that later entries in the default branch path are read only,
  414.   i.e. one cannot check in changes to them.
  415.   This should be an option settable by RCSINIT.
  416.  
  417.   Have `rlog -nN F' print just the revision number that N translates to.
  418.   E.g. `rlog -nB. F' would print the highest revision on the branch B.
  419.   Use this to add an option -bB to rcsbranch, to freeze the named branch.
  420.   This should interact well with default branches.
  421.  
  422. The following projects require a change to RCS file format,
  423. and thus must wait until at least RCS version 6.
  424.  
  425.   Be able to store RCS files in compressed format.
  426.   Don't bother to use a .Z extension that would exceed file name length limits;
  427.   just look at the magic number.
  428.  
  429.   Add locker commentary, e.g. `co -l -m"checkout to fix merge bug" foo'
  430.   to tell others why you checked out `foo'.
  431.   Also record the time when the revision was locked,
  432.   and perhaps the working pathname (if applicable).
  433.  
  434.   Let the user mark an RCS revision as deleted; checking out such a revision
  435.   would result in no working file.  Similarly, using `co -d' with a date either
  436.   before the initial revision or after the file was marked deleted should
  437.   remove the working file.  For extra credit, extend the notion of `deleted' to
  438.   include `renamed'.  RCS should support arbitrary combinations of renaming and
  439.   deletion, e.g. renaming A to B and B to A, checking in new revisions to both
  440.   files, and then renaming them back.
  441.  
  442.   Be able to check in an entire directory structure into a single RCS file.
  443.  
  444.   Use a better scheme for locking revisions; the current scheme requires
  445.   changing the RCS file just to lock or unlock a revision.
  446.   The new scheme should coexist as well as possible with older versions of RCS,
  447.   and should avoid the rare NFS bugs mentioned in rcsedit.c.
  448.   E.g. if there's a reliable lockd running, RCS should use it
  449.   instead of relying on NFS.
  450.  
  451.   Add rcs options for changing keyword names, e.g. XConsortium instead of Id.
  452.   Add a Description keyword; but this may be tricky, since descriptions can
  453.   contain newlines and $s.
  454.  
  455.   Add frozen branches a la SCCS.  In general, be able to emulate all of
  456.   SCCS, so that an SCCS-to-RCS program can be practical.  For example,
  457.   there should be an equivalent to the SCCS prt command.
  458.  
  459.   Add support for distributed RCS, where widely separated
  460.   users cannot easily access each others' RCS files,
  461.   and must periodically distribute and reconcile new revisions.
  462.  
  463.   Be able to create empty branches.
  464.  
  465.   Be able to store just deltas from a read-only principal copy,
  466.   e.g. from source on CD-ROM.
  467.  
  468.   Improve RCS's method for storing binary files.
  469.   Although it is more efficient than SCCS's,
  470.   the diff algorithm is still line oriented,
  471.   and often generates long output for minor changes to an executable file.
  472.  
  473.   Add a new `-kb' expansion for binary files on non-Posix hosts
  474.   that distinguish between text and binary I/O.
  475.   The current `text_work_stdio' compile-time switch is too inflexible.
  476.   This fix either requires nonstandard primitives like DOS's setmode(),
  477.   or requires that `-kb' be specified on initial checkin and never changed.
  478.   From the user's point of view, it would be best if
  479.   RCS detected and handled binary files without human intervention,
  480.   switching expansion methods as needed from revision to revision.
  481.  
  482.   Extend the grammar of RCS files so that keywords need not be in a fixed order.
  483.  
  484.   Internationalize messages; unfortunately, there's no common standard yet.
  485.   This requires a change in RCS file format because of the
  486.   `empty log message' and `checked in with -k' hacks inside RCS files.
  487.  
  488.  
  489. Credits:
  490.  
  491.   RCS was designed and built by Walter F. Tichy of Purdue University.
  492.   RCS version 3 was released in 1983.
  493.  
  494.   Adam Hammer, Thomas Narten, and Dan Trinkle of Purdue supported RCS through
  495.   version 4.3, released in 1990.  Guy Harris of Sun contributed many porting
  496.   fixes.  Paul Eggert of System Development Corporation contributed bug fixes
  497.   and tuneups.  Jay Lepreau contributed 4.3BSD support.
  498.  
  499.   Paul Eggert of Twin Sun wrote the changes for RCS version 5, released in 1991.
  500.   Rich Braun of Kronos and Andy Glew of Intel contributed ideas for new options.
  501.   Bill Hahn of Stratus contributed ideas for setuid support.
  502.   Ideas for piece tables came from Joe Berkovitz of Stratus and Walter F. Tichy.
  503.   Matt Cross of Stratus contributed test case ideas.
  504.   Adam Hammer of Purdue QAed.
  505.